It is known to apply virtualization to network functions in communications networks. Benefits of such network function virtualization NFV derive partly from replacing silos of monolithic and proprietary (and therefore expensive) hardware service platforms in the communications infrastructure by abstracted services run as applications on an open and commodity (and therefore cheaper) compute, storage and network infrastructure. An example architectural framework is under development within the European Telecommunications Standards Institute (ETSI) known as NFV, and some features of this are summarized below with respect to FIG. 8.
Telecoms networks currently contain a variety (which is tending to increase) of proprietary hardware appliances. Each network service may use a separate hardware appliance. Hardware lifecycles are becoming shorter, reducing the return on investment of deploying new services in an increasingly network-centric world. NFV is a new network operator-led Industry Specification Group (ISG) in ETSI to work through the technical challenges for Network Functions Virtualization. Network Functions Virtualization (NFV) aims to address these problems by evolving standard IT virtualization technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage.
NFV involves implementing network functions in software that can run on a range of industry standard server hardware, and that can be moved to, or instantiated in, various locations in the network as required, without the need to install new equipment. NFV decouples software implementations of Network Functions from the compute, storage, and networking resources through a virtualization layer.
In addition to traditional Fault, Configuration, Accounting, Performance, and Security (FCAPS) Management, the NFV Management and Orchestration framework (MANO) introduces a new set of management functions associated with the lifecycle management of a VNF. The NFV ISG has focused on detailing these new sets of management functions, which include, but are not limited to: on-board a VNF, instantiate a VNF, scale a VNF, update a VNF, and terminate a VNF. Notably in fault and performance management in a virtualized environment, different functional blocks at different layers are involved. As a result more coordination may be needed between the infrastructure and the VNF instantiated depending on their peculiar characteristics.
Complex network functions, when virtualized can be mapped to a more than one virtual machine. On processing hardware such as a server, more than one component of a VNF can run in each separate virtual machine and many virtual machines can run on a server. The servers may be located inside a cloud data center.
Where it is desirable to provide some redundancy to protect against faults (HW and/or SW), it is known to specify an anti affinity (AA) rule. In Virtual/Cloud environments, AntiAffinity (AA) rules prevent more than one VNFCI from the same group of instances (such as N+M instances of a single VNFC where N is the minimum number of instances desired, and M is the number of additional instances to provide redundancy) being loaded and running on the same host. This can prevent a single HW/Hypervisor fault from causing loss of multiple instances at once. So in this case there are N+M instances each allocated to a different physical host.